In recent years, an increasing number of providers have been offering the ability to create computing environments in the cloud. For example, in 2006, Amazon Web Services™ (also known as AWS) launched a service that provides users with the ability to configure an entire environment tailored to an application executed over a cloud-computing platform. In general, such services allow for developing scalable applications in which computing resources are utilized to support efficient execution of the application.
Organizations and businesses that develop, provide, or otherwise maintain cloud-applications have become accustomed to relying on these services and implementing various types of environments, from complex websites to applications and services provided via the software-as-a-service (SaaS) delivery model. Such services and applications are collectively referred to as “cloud applications.” Cloud applications are typically accessed by users using a client device via a web browser.
Cloud applications are typically programmed to support multi-tenancy access or resource sharing. A multi-tenancy is an architecture in which a single instance of a software application (e.g., a cloud-application) serves multiple customers, where a customer is a tenant. Tenants may customize some resources of the application, such as color of the user interface (UI) or business rules, but they cannot customize the application's code.
To allow scalability and low latency in cloud applications supporting multi-tenancy architecture, instances of the same application are hosted in multiple datacenters. Further, tenants (or their data) reside in different datacenters. The datacenters are geographically distributed. Typically, a datacenter would serve clients in its geographic location. For example, clients from Europe would access a cloud application hosted in a datacenter located in Germany.
Currently, there are two techniques allowing a client device to communicate or otherwise access the datacenter supporting its tenant. These techniques are based on URL-redirection and forward proxy, and are further described herein below with reference to FIG. 1.
The example network 100 illustrated in FIG. 1 includes client devices 110-1 and 110-2, datacenters 120 and 130, a single-sign-on (SSO) server 140, and a proxy 150, communicatively connected through a network 160. Each of the datacenters 120 and 130 hosts a single-page application (SPA) 170 that supports a multi-tenancy architecture.
In SPAs, a single HTML page is loaded to a browser of a client device and is dynamically updated as the user interacts with the application. Typically, the single web page includes all necessary code (e.g., HTML, JavaScript, and CSS) to be rendered on the browser. Interaction with the server hosting a single-page application is performed using protocols, such as AJAX and HTML5, to create responsive web applications without constant page reloads.
When redirecting a client device to access the datacenter supporting its tenant, upon authentication of a user of the client device 110-1, for example by means of the single-sign-on (SSO) server 140, the client device 110-1 is redirected to a datacenter, e.g., the datacenter 120. The redirection is performed by returning, to the client device 110-1, a URL (a redirected URL) of the datacenter 120 hosting the application's tenant associated with a user of the client device 110-1. The redirected URL is displayed on the browser of the client device 110-1, thereby exposing the URL of the datacenter. For example, if the client device 110-1 initially accesses a URL portal.myapp.com and the datacenter serving the client is in Europe, the URL returned by the SSO server 140 may be europe_site.portal.myapp.com. Forcing a redirect of the request would require issuing a new server certificates per datacenter supporting the modified URL.
Another technique for directing a client device to a datacenter supporting its tenant is using a proxy 150. The proxy 150 is configured to receive requests from the client devices 110-1 and 110-2, and to forward the received requests to a datacenter serving a particular client's tenant. For example, requests received from the client device 110-1 to an application addressed by portal.myapp.com can be directed to the datacenter 120, while requests received from the client device 110-2 to the same URL can be directed to the datacenter 130. The association between datacenters and client devices can be preconfigured in the proxy 150. The proxy 150 is typically a reverse proxy.
Using a reverse proxy complicates the solution, as use of the proxy requires additional hardware resources to be deployed in the network, increasing latency by forcing another hop for the traffic, and maintaining, by a reverse proxy, a current database on the association between datacenters to client devices.
As greater reliance is made on cloud applications, the access to such applications from a web browser must be completely secured, without latency, and must further be seamless.
It would therefore be advantageous to provide a solution that would overcome the deficiencies noted above by allowing seamless access to datacenters hosting cloud applications supporting multi-tenancy.